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REMARKS/ARGUMENTS 

Reconsideration and allowance of this application are respectfully requested. Currently, 
claims 1-10 are pending in this application. 
Drawings ; 

Applicant filed a corrected sheet of drawings including changes to Fig. 4. Applicant 
assumes that this corrected sheet has been accepted by the USPTO, and requests notice to this 
effect. 

Information Disclosure Statement (IDS) ; 

With respect to Applicant's IDS filed March 21, 2006, Applicant assumes that all of the 
cited references have been considered - even though the returned Form PTO/SB/08a was not 
labeled "ALL REFERENCES CONSIDERED EXCEPT WHERE LINED THROUGH" like the 
returned Form PTO/SB/08a of the IDS filed October 4, 2006. Applicant requests clarification if 
this assumption is incorrect. 
Rejection under 35 U,S,C, S102 : 

Claims 1-10 were rejected under 35 U.S.C. §102 as allegedly being anticipated by 
Rosenberg et al. (U.S. *373, hereinafter "Rosenberg"). Applicant traverses this rejection. 

Anticipation under Section 102 of the Patent Act requires that a prior art reference 
disclose every claim element of the claimed invention. See, e.g., Orthokinetics, Inc, v. Safety 
Travel Chairs. Inc., 806 F.2d 1565, 1574 (Fed. Cir. 1986). Rosenberg fails to disclose every 
claim element of the claimed invention. For example, Rosenberg fails to disclose the following 
limitations of independent claim 7 and its dependents (similar comments apply to claim 1 and its 
dependents): 
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"deriving a model of the space in which directional forces are being applied and storing 
data defining said model, 

deriving from the historic positional data and the data defining the model an anticipated 
position and 

generating output signals defining force and direction to move the haptic output device 
towards said anticipated position and 

correcting for differences between the anticipated position and the transmitted position on 
receipt of subsequent positional data.*' 

In conventional arrangements, the position to be taken by a haptic device at a first, local, 
location would be dependent on and determined by the position of a haptic device at a second, 
remote, location. Where the two haptic devices are separated by for example a connectionless 
network, network latency can be a significant issue. Delays in the transmission of positional data 
can cause the respective devices to operate out of sync with each other, thereby adversely 
affecting the quality of the user experience. Delays in the transmission of the positional data 
between the devices could also cause instability in at least one of the haptic devices, thereby 
possibly resulting in damage to the haptic device. 

Example embodiments of the present invention relate to method/system in which the 
position of the local haptic device is dependent not only on the positional data of the remote 
haptic device. To compensate for latency, the exemplary method/system calculates an 
anticipated position for the local haptic device, which is used together with data about the 
position of the remote device to move the local haptic device to the position it should assume. 
As noted in by the paragraph beginning on page 7, line 32 of the original specification, a number 
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of methods to predictive methods are available, including those based on "building a model of 
the remote environment and force field modeling." 

One example embodiment is described in Figure 6 and page 8 of original specification. 
Here, the local device receives data about the position of the remote device, which is stored in a 
record (61), Based on previous position(s) of the remote device, its next position can be 
predicted, which would determine the forces needed to coerce the local device to the position it 
needs to assume. As described in Figure 7 and the paragraph beginning on page 9, line 1 1 of the 
original specification however, the forces are modified by reference to data from the model of 
the force field (75, 76). As fiirther described on page 9, line 1 1 to page 10, line 17 of the original 
specification, a data model can also be built of the spatial environments in which the devices are 
operating, so that "combinations of force modelling and space modelling may be used to 
influence the final output to the motors" (which actuate the devices, page 10, lines 14-16 of the 
original specification). As noted above, the spatial model refers to the virtual environment in 
which the device operates: in the example given in the paragraph beginning at page 9, line 25, 
the environment or space "has a solid object of known mechanical properties." 

Page 3 of the Office Action alleges that col. 48, lines 37-64 of Rosenberg discloses 

"deriving a model of the space in which directional forces are being applied and storing data 

defining said model (emphasis added)" as required by claim 7. Applicant disagrees with this 

allegation. Col. 48, lines 37-64 of Rosenberg states the following: 

In step 458, process 388 adds the force value computed in step 456 to 
the total force for the axis initialized in step 452. In alternate embodiments, 
process 388 may limit the total force value or a portion of the total force value 
computed in step 458. For example, if process 388 is keeping track of which 
force values are condition forces and which force values are overlay forces, 
the process 388 can limit the sum total of condition forces to a predetermined 
percentage of maximum actuator force output, such as 70% of maximum 
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output. This allows some of the available force range to be used for overlay 
forces, such as button jolts, vibrations, etc. that may applied on top of the 
condition forces. This limiting is preferably performed after all condition 
forces that are in effect have been computed, so that overlay forces can be 
applied over the sum of all condition forces. Other forces can be limited in 
altemate embodiments. 

In next step 460, process 388 determines if another reflex process 
needs to be executed for the currently selected axis. This would be true if 
additional host commands are in effect for which forces have not yet been 
computed and added to the total force. If so, the process retums to step 456 to 
check the force parameters, execute another reflex process to compute a force, 
and add that force to the total force. If, in step 460, there are no more reflex 
processes to be executed for the selected axis, then total force represents all 
forces in effect on the selected axis. Total force for the selected axis is then 
stored in memory 27 in step 462. 

The above-reproduced portion of Rosenberg describes how force values may 
be computed for application to the axis or degree of freedom of the haptic interface. 
There is nothing in this portion which relates in the least to the modelling of the 
operational space, aside from the coincidence of the word "stored" in column 48, line 
64, with the storage of the modelling data required by claim 7. In Rosenberg, the 
need for storage arises due to the execution of processes of the microprocessor local 
to the haptic interface parallel with the host computer's activities. The local 
microprocessor and the host computer do work in parallel with each other, but the 
microprocessor is nowhere described to have "derived" a data model of the host 
computer, for example. 

Pages 4-5 of the Office Action then apparently alleges that col. 17, lines 1-26; 
col. 18, line 46 to col. 19, line 6; and col. 29, lines 57-67 of Rosenberg discloses 
"deriving a model of the space in which directional forces are being applied and 
storing data defining said model (emphasis added)" as required by claim 7. Applicant 
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disagrees with this allegation. These portions of Rosenberg state the following 

(emphasis added): 

The low-level force commands can be determined, in part, from a 
selected force sensation process, A "reflex process" or "force sensation 
process", as referred to herein, is a set of instructions for providing force 
commands dependent on other parameters, such as sensor data read in step 78 
and timing data from clock 18. In the described embodiment, force sensation 
processes can include several different types of steps and/or instructions. One 
type of instruction is a force algorithm, which includes an equation that host 
computer 12 can use to calculate or model a force value based on sensor and 
timing data. Several types of algorithms can be used. For example, algorithms 
in which force varies linearly (or nonlinearly) with the position of object 34 
can be used to provide a simulated force like a spring. Algorithms in which 
force varies linearly (or nonlinearly) with the velocity of object 34 can be also 
used to provide a simulated damping force or other forces. Algorithms in 
which force varies linearly (or nonlinearly) with the acceleration of object 34 
can also be used to provide, for example, a simulated inertial force on a mass 
(for linear variation) or a simulated gravitational pull (for nonlinear variation). 
Several types of simulated forces and the algorithms used to calculate such 
forces are described in "Perceptual Design of a Virtual Rigid Surface 
Contact," by Louis B. Rosenberg, Center for Design Research, Stanford 
University, Report number AL/CF-TR- 1995-0029, April 1993, which is 
incorporated by reference herein. 

« 4c ♦ ♦ * 

Another type of force sensation process does not use algorithms to 
model a force , but instead uses force values that have been previously 
calculated or sampled and stored as a digitized "force profile" in memory or 
other storage device. These force values may have been previously generated 
using an equation or algorithm as described above, or provided by sampling 
and digitizing forces. For example, to provide a particular force sensation to 
the user, host computer 12 can be instructed by a force sensation process to 
retrieve successive force values from a certain storage device, such as RAM, 
ROM, hard disk, etc. These force values can be sent directly to an actuator in 
a low-level command to provide particular forces without requiring host 
computer 12 to calculate the force values. In addition, previously-stored force 
values can be output with respect to other parameters to provide different 
types of forces and force sensations from one set of stored force values. For 
example, using system clock 18, the stored force values can be output in 
sequence according to a particular time interval that can vary depending on 
the desired force. Or, different retrieved force values can be output depending 
on the current position of user object 34. 
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Host computer 12 can determine a force command in step 82 
according to a newly-selected reflex process, or to a previously selected reflex 
process. For example, if this is a second or later iteration of step 82, the same 
reflex process as in the previous iteration can be again implemented if 
parameters (such as the position of object 34) allow it, as determined by the 
host application program. 

>|c ♦ ♦ ♦ 4e 

In one embodiment, the host command is permitted to include 
command parameters generic to a wide variety of force models implemented 
by the microprocessor 26 to control the actuators 30. For instance, force 
magnitude and force direction are two generic command parameters. Force 
duration, or force model application time, is another generic command 
parameter. It may also be advantageous to further define a command 
parameter for other input device 39, such as a button. The button, when 
activated, can trigger different forces or force models. 

Each and every one of the above reproduced portions of Rosenberg discloses the 
modeling o f forces to be applied, but none of them refer to a space model. Rosenberg therefore 
does not describe "a model of the space in which directional forces are being applied at said one 
location." In short, Rosenberg*s force model does not disclose the claimed space model. 

Also, pages 3 and 5 of the Office Action alleges that col. 31, lines 56-63 and col. 37, lines 

60-67 of Rosenberg disclose "deriving from the historic positional data and the data defining the 

model an anticipated position and generating output signals defining force and direction to move 

the haptic output device towards said anticipated position and correcting for differences between 

the anticipated position and the transmitted position on receipt of subsequent positional data 

(emphasis added)," as required by claim 7. Applicant disagrees with this allegation. Col. 31, 

lines 56-63 and col. 37, lines 60-67 of Rosenberg state the following (emphasis added): 

Command parameters 304 are values or indicators provided by the 
host computer 1 2 which customize and/or modify the type of force indicated 
by command portion 304. Many of the conraiands use magnitude, duration, or 
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direction command parameters. Some commands include a style parameter 
which often modifies a force's direction. Other particular command 
parameters are provided for specific forces, as described in detail below. 

***** 

A vector force is a general force having a magnitude and direction. 
Refer to FIG. 12 for a polar representation of the vector force. Most position 
control sensations will be generated by the programmer/developer using a 
vector force command and appropriate instructions and programming 
constructs. A duration parameter is typically not needed since the host 12 or 
microprocessor 26 can terminate or modify the force based on user object 
motions, not time. 

The above reproduced portions of Rosenberg merely refer to how types of force may be 
customized or modified by use of a style parameter, or else the force may be modified based on 
user object motions (see boldfaced language in the above reproduced portions of Rosenberg). 
The fact that the above reproduced portions of Rosenberg merely contains the word "modified" 
does not mean the that the above reproduced portions of Rosenberg disclose "correcting", let 
alone correcting for differences between the anticipated position and the transmitted position on 
receipt of subsequent positional data - as claimed. 

The Office Action also makes reference to steps 80, 92 and 84 in the flow chart of Figure 
4. However, these steps merely refer to the changes in position which the haptic device (being a 
haptic device) undergoes during use. These steps do not perform a "correction", and certainly 
not one which corrects for "differences between the anticipated position and the transmitted 
position" as claimed. 

Rosenberg is not concerned with the effects of latency (as the host computer and the 
force feedback interface device are not separated by a connectionless network, but by a simple, 
short bus link). One skilled in the art would never consider adding to the computational overhead 
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by arranging for (for example) the interface device to predict what the host computer may issue 
by way of high level commands using a model and then correcting for differences in view of the 
teachings of Rosenberg. 

As described above, nothing in the above-reproduced portions of Rosenberg disclose 
correcting for differences between the anticipated position and the transmitted position on receipt 
of subsequent positional data. For example, nothing is described what the "differences" relate to: 
in the invention of claim 7 this is between the anticipated position and the actual position the 
haptic device should move to, per transmitted positional data received subsequently. There is 
also no any disclosure that, in the first place, the anticipated position is specifically derived from 
historic positional data and the modeled space. Again, a mere recitation of the word "modify" in 
Rosenberg simply does not disclose or suggest the claimed correcting for differences between 
the anticipated position and the transmitted position on receipt of subsequent positional data. 

Additionally, Rosenberg fails to disclose the use of packet data which defines a position 
measured at one location for transmission to the current location. This is because Rosenberg's 
system, in which components are connected by a bus link, does not require packetized data. 

Accordingly, Applicant respectfully requests that the above noted rejection under 35 
U.S.C. §102 be withdrawn. 
Conclusion : 

Applicant believes that this entire application is in condition for allowance and 
respectfully requests a notice to this effect. If the Examiner has any questions or believes that an 
interview would further prosecution of this application, the Examiner is invited to telephone the 
undersigned. 
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RYM:dmw 

901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
Facsimile: (703)816-4100 



Respectfully submitted. 



NIXON & VANDERHYE P.C. 
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